Systems and methods for multifactor authentication

ABSTRACT

The invention provides an authentication system and method. In particular, the invention provides a method for performing a financial authentication utilizing a token associated with a user, the method comprising the token generating a set of display characters that are viewable by the user, the token generating the display characters using logic; the user transforming a portion of the set of display characters using a transformation process, based on knowledge of the user, so as to form a display character sequence; the user outputting the display character sequence to an authentication entity; and the authentication entity authenticating the display character sequence using the logic and knowledge of the transformation.

CROSS REFERENCE TO PROVISIONAL APPLICATIONS

This application is a Continuation-in-Part (CIP) application of U.S.patent application Ser. No. 10/419,107 filed Apr. 21, 2003 (AttorneyDocket No. 47004.000204), which is a Continuation-in-Part (CIP)application of U.S. patent application Ser. No. 10/105,471 filed Mar.25, 2002, both of which are incorporated into the present application intheir entirety.

The subject matter of this application is related to the subject matterof U.S. Provisional Application Ser. No. 60/646,622 filed Jan. 26, 2005(Attorney Docket No. 47004.000322), assigned or under obligation ofassignment to the same entity as this application, from whichapplication priority is claimed for the present application. The subjectmatter of this application is also related to the subject matter of U.S.Provisional Application Ser. No. 60/661,488 filed Mar. 15, 2005(Attorney Docket No. 47004.000322), assigned or under obligation ofassignment to the same entity as this application, from whichapplication priority is claimed for the present application. Provisionalapplication U.S. Ser. No. 60/646,622 and Provisional application U.S.Ser. No. 60/661,488 are both incorporated herein by reference in theirentirety.

BACKGROUND OF THE INVENTION

Authenticating people, particularly remotely, has been a difficultoperation to make resistant to attack. Since single authenticatingtechniques are vulnerable to theft, it has become attractive to variousgroups to devise ways to do multi factor authentication, where more thanone of (something you have, something you know, something you are) isused in demonstrating the identity of a person whose identity is to beestablished.

Typically, doing this has involved using relatively complex or expensivedevices such as cards with keyboards on them (where you authenticate tothe card and then use it), fingerprint readers, or digital certificatesrequiring public/private encryption to validate the presenter is inpossession both of a password and of a private key.

All this complexity has delayed widespread use of such systems, sincethe cost of giving out hundreds of millions of copies of them has beenkept high by the need to authenticate two or more things, and the costof building the system components.

SUMMARY AND BRIEF DESCRIPTION OF THE INVENTION

The invention provides an authentication system and method. Inparticular, the invention provides a method for performing a financialauthentication utilizing a token associated with a user, the methodcomprising the token generating a set of display characters that areviewable by the user, the token generating the display characters usinglogic; the user transforming a portion of the set of display charactersusing a transformation process, based on knowledge of the user, so as toform a display character sequence; the user outputting the displaycharacter sequence to an authentication entity; and the authenticationentity authenticating the display character sequence using the logic andknowledge of the transformation.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be more fully understood by reading thefollowing detailed description together with the accompanying drawings,in which any like reference indicators are used to designate likeelements, and in which:

FIG. 1 is a diagram showing aspects of an encryption process inaccordance with one embodiment of the invention;

FIG. 2 is a flowchart showing further aspects of the encryption processin accordance with one embodiment of the invention;

FIG. 3 is a block diagram showing an authentication system in accordancewith one embodiment of the invention;

FIG. 4 is a block diagram showing further details of an authenticationsystem, and in particular the authentication entity system, inaccordance with one embodiment of the invention;

FIG. 5 is a diagram showing processing associated with displaycharacters in accordance with one embodiment of the invention;

FIG. 6 is a high level flowchart showing an authentication process inaccordance with one embodiment of the invention;

FIG. 7 is a flowchart showing further details of the “customer generatesauthentication information” step of FIG. 6 in accordance with oneembodiment of the invention;

FIG. 8 is a flowchart showing in further detail the “authenticationentity system authenticates the billing information, includingauthenticating the display character sequence” step of FIG. 6 inaccordance with one embodiment of the invention;

FIG. 9 is a flowchart showing in further detail the “authenticatorcharacter generating portion generates an authorizing character sequencebased on the authentication characters” step of FIG. 8 in accordancewith one embodiment of the invention;

FIG. 10 is a flowchart showing in further detail the “display charactersequence is compared to the authorizing character sequence” step of FIG.8 in accordance with one embodiment of the invention; and

FIG. 11 is a diagram showing further aspects of an encryption processrelating to a purchase amount in accordance with one embodiment of theinvention.

DETAILED DESCRIPTION OF THE INVENTION

Hereinafter, various aspects of embodiments of the invention will bedescribed. As used herein, any term in the singular may be interpretedto be in the plural, and alternatively, any term in the plural may beinterpreted to be in the singular.

What is proposed here is a system and method which provides a form oftwo factor authentication which resists theft of the authenticationtokens even by someone who can intercept the authentication messages intotal, in accordance with one embodiment of the invention. The inventioncan be supported using relatively very simple hardware.

One embodiment uses a token which displays numbers that change (eitherwith time or with uses, but in ways that cannot be easily predicted byobservation) but whose values can be tracked and predicted by anauthenticating authority (who issued the tokens generally). Inaccordance with one embodiment of the invention, the token will displaya set of numbers which will have their positions labeled (e.g., 1through 6, for a 6 digit display). FIG. 1 is a diagram illustrating sucha token 100.

In accordance with one embodiment of the invention, a customer will betold ahead of time, “choose three positions of the display 10, as shownin FIG. 1, you will select in order, and remember the positions andorder you picked.” The customer authenticates by getting his token todisplay a new set of numbers (which should change so that their valuesare effectively unpredictable), and then to report the values in thethree positions he chose and told the authenticating authority aboutearlier.

FIG. 1 shows the display of the token 100 in an “off” position. Once thecustomer activates the display in some manner, i.e., pushes a button,the token is turned on, and numbers are seen on the display. Thus, asshown in FIG. 1, suppose the display 10 reads: and the customer decidedto report position 5, 1, and 4 in that order. The customer would thentransmit the 5th, 1st, and 4th digits in order: 2 5 9

Note that this authenticates the customer as an individual since thecustomer demonstrates that he knows the pattern registered earlier, butalso it shows the customer has the token he was given. Thus, at a strokehe has provided a two factor authenticator. Note too that someone whocan see the digits sent cannot replay them usefully. That person doesnot know the pattern, nor does she have the token, and she must haveboth to use the token successfully.

In accordance with one embodiment of the invention, another set oflabels may be provided under the display, like 01, 23; 45, 67, 89. Inprocessing a transaction, the customer is asked, later in a transaction,to encode a few digits of the transaction amount as positions of thedisplay, and then requested to transmit the digits. This too can beeasily verified by a payment processor (who has the amount as part of apayment record), and it shows that someone with the token agreed to thepayment amount. In effect, this is a signing by the customer (who wouldhave authenticated as an individual moments before with the same token)of the transaction amount. Similarly, any external observer will beunable to deduce any of this from the digits transmitted. The customermay be told what the purchase amount is. Accordingly, for example, ifthe customer is told the purchase amount was $872.00, the customer wouldreport the characters shown in the position five, position five andposition two, i.e., if the display was labeled 0, 1-2, 3-4, 5-6, 7-8, 9.

In further illustration, FIG. 11 shows a token 30 so labeled. In thisexample, the displayed number is 5 3 7 9 2 1. Accordingly, with apurchase amount of $872, the customer would report the displayed numbersin the positions, 5, 5, 2, i.e., the customer would report the numbers 22 3. In this manner, an authentication entity can confirm that thecustomer indeed knows what the customer is agreeing to, e.g., a dollaramount. It is appreciated that such processing adds complexity, but maybe desired in some circumstances, e.g., in high dollar transactions. Toreduce the complexity, a prompt screen might be provided to the customerso as to take them through the process, e.g., a window on a web page.

It is appreciated that an alternative data manipulation that can be doneby the user-customer could be used here instead of the pattern selectiondescribed above. That is, the customer does need to manipulate thedisplayed numbers in some manner known to him (and the authenticatingauthority) so as to generate an output from such manipulation. However,the selection scheme described above may be desirable since it appearseasy to use and remember by the customer

In implementation of the invention, it is not needed that numbers beused on the display. That is, any of a wide variety of graphics,letters, symbols, glyphs, runes, images or other indicia, for example,might be used in lieu (or in combination) with numbers.

It should be appreciated that the various features of the presentinvention may be used in conjunction with other encryption technologyand/or features. In particular, the various features of the presentinvention may be used in combination with any of the features describedin U.S. patent application Ser. No. 10/419,107 filed Apr. 21, 2003(attorney docket number 47004.000204), which is incorporated herein byreference in its entirety.

In explanation of further aspects, in accordance with one embodiment ofthe invention, the problem being addressed is in the area ofauthentication. Authentication of customers to a bank is vital since theentire business is involved with caring for other peoples' money andusing it per their instructions. If the owners cannot be identified,their instructions cannot be followed and the business collapses. Whentrying to identify people over computer links, this is harder thanotherwise. One of the major issues is that spyware and other man in themiddle attacks on information passed for authentication are very common.By providing people with a token that can produce an effectively randomnumber which an authority can compute as well, anytime it is needed,people might be able to prove clearly that they have the token.Unfortunately, theft of tokens (even from the mails) is also common. Itis desirable in addition to know for high value transactions that one isdealing with the person who claims to be dealing with you rather thanknowing only that whoever you are dealing with has the person's token.Moreover, while it is common practice just to ask for another passwordor PIN (personal identification number), these are all too easilyintercepted. The proposed scheme here solves those problems.

Hereinafter, the invention will be described from a further perspective,in accordance with one embodiment. Given that two parties who mustauthenticate one to the other both have means to generate an effectivelyrandom number (which means it is computationally infeasible to computethe next such number from the prior ones without a secret shared by thetwo) which can nevertheless be generated by both and tracked so that theone doing the authentication can (1) figure out the value the other onehas, (2) find some transformation of the number or part of it which canbe easily done by hand, and (3) have both parties agree to thistransform (which can be thought of as a simple encryption) ahead oftime. Now when the one not doing the authentication needs toauthenticate the other, make sure they have generated a “random” numberand have the one being authenticated perform the agreed on operation andreport the value thereof. This may be as simple as picking an order inwhich to report several of the digits of the random number, as describedabove. Then, the one doing the authentication performs the sametransform on his copy of the random number and checks if the value iscorrect. Note that anyone observing the numbers picked will see only therandom numbers, not the secret method by which they were produced, andthus will have nothing very useful in attempting a replay or PIN theft.

To explain further, the ideas of doing a second encryption, and that ofpermuting numbers or using a Caesar cipher, are old. However, the schemehere, because it is used with effectively random numbers, is muchstronger than a permutation or Caesar cipher or other hand encryptionmethod because of the absence of usable order in the material beingencoded. An attacker must solve a cipher on a “plaintext” random numberwhich in general is generated every time needed and used once. Thismakes it exceedingly difficult for a man in the middle to steal theperson's authentication. Also, whatever token system is used to providethe pseudo random numbers and track them or synchronize them needs noadditional complexity. This makes the scheme more cost effective thansystems using conventional passwords or PINs, digital certificates, andother such complexities.

FIG. 2 is a flowchart in accordance with one embodiment of theinvention. As shown, the present invention provides a novel way toauthenticate a customer or other person.

The invention might be compared to a known one-time pad. One time padcryptography is usually illustrated with the pad values being XORed withdata. In effect, embodiments of the invention perform an encryption handoperation on display characters displayed by a token. As shown in theexample of FIG. 2, if the “random number” choices are changedappropriately, we could produce 3 digit outputs from 000 to 999, i.e.,the entire range possible. This means we may have no test possible topick the correct key as an observer in the middle. This makes theoperation the user undertakes (which might be the illustratedpermutation or anything else convenient) far stronger than what the sameoperation on normal text might be. The user operation remains a simpleone, but the fact that it operates on one time data which is effectivelyrandom makes it basically as strong as the randomness. Where the cipherand key are well chosen which may be used for computing the numbers tobe synchronized the resulting ciphertext may be treated as random andthe discussion above holds.

FIG. 3 is a block diagram showing an authentication system 100 inaccordance with one embodiment of the invention. The authenticationsystem 100 includes a user authentication device 120. The userauthentication device 120 may be in the form of a token, for example.The user authentication device 120 provides the user with displaycharacters (for example numbers) 192 (see FIG. 3) that are used by theuser to effect an authentication, as discussed below.

As shown in FIG. 3, the user authentication device 120 includes adisplay character generating portion 124 and a display portion 130. Thedisplay portion 130 includes a plurality of display positions 138, i.e.,display positions (131-136). Each display position 138 is a display,i.e., such as an LCD display, that displays a number, or any othercharacter, so as to be visually observed by a user 110, in accordancewith one embodiment of the invention.

The display character generating portion 124 generates the charactersthat are displayed in the display portion 130. In particular, thedisplay character generating portion 124 uses predetermined logic (i.e.,a suitable algorithm) to populate the display positions 138. This logicprovides a predetermined progression of numbers, or other characters,that may be similarly generated by an authentication entity system 140.

In accordance with one embodiment of the invention, the userauthentication device 120 has a button 121, which may be pressed by auser 110. Upon pressing the button 121, the display character generatingportion 124 generates the characters that are displayed in the displayportion 130. Accordingly, the user 110 interfaces with the userauthentication device 120 using the button and visually, in accordancewith one embodiment of the invention.

The user authentication device 120 further includes a device memoryportion 126. The device memory portion 126 serves as a memory ordatabase, as is needed to perform the various functions of the userauthentication device 120.

As shown in FIG. 3, the authentication system 100 also includes anauthentication entity system 140 and an illustrative merchant 180.Illustratively, the user 110 (using the user authentication device 120)interfaces with the merchant 180 so as effect a desired transaction. Thetransaction might be over the telephone, the Internet, or any othercommunication channel, as desired.

Accordingly, the systems and methods of embodiments of the invention maybe used in any “transaction”, including a conveyance of information, inwhich authentication of a user is needed or desired. Such transactionmight include a telephone transaction, Internet transaction (such as anInternet purchase), network transaction, infrared transaction, radiosignal transaction, credit card transaction, debit card transaction,smart card transaction, ACH transaction, stock trade transaction, mutualfund transaction, swap, PAYPAL® transaction, BILL ME LATER® transaction,electronic funds transfer transaction, financial applicationtransaction, an arrangement to set up payments to an entity, averification, an ATM transaction, and/or a message, for example. Forexample, such a transaction might include a message from one human userto another human user, a human user communicating with an electronicdevice, and/or two electronic devices communicating with each other. Thetransaction may or may not be in a financial context, i.e., for example,the message might be authorizing the opening of a door or the transferof a non-financial related message, for example.

Accordingly, FIG. 3 shows a communication channel 160 over which thetransaction is performed. The communication channel 160 carries anauthorization request 162. Subsequent to the request being processed bythe authentication entity system 140, the communication channel 160 thencarries an authorization 164, in the example of FIG. 3. However, it isof course appreciated that the authentication entity system 140 mightalternatively not authorize the requested transaction. As shown in FIG.3, the authorization request 162 and the provided authorization ispassed through the merchant 180. However, in an alternative embodiment,the authorization request 162 and/or the authorization provided 164might be communicated to the authentication entity system 140 in someother manner, such as by some third party, and not via the merchant 180.Further, it is appreciated that the user authentication device 120 neednot take on the form of the device shown in FIGS. 1 and 3, for example.That is, for example, the user authentication device 120 might be in theform of a software program running on a computer, or in some otheralternative form.

FIG. 4 is a block diagram showing further details of the authenticationentity system 140. The authentication entity system 140 includes aninput portion 142 and an entity memory portion 144. The input portion142 interfaces with the communication channel 160 so as to communicatedata, i.e., such as the authorization request 162 and the authorizationprovided 164 information. The entity memory portion 144 serves as adatabase to store various data associated with, and needed by, operationof the authentication entity system 140.

The authentication entity system 140 also includes an authenticatingprocessing portion 150. The authenticating processing portion 150performs the various processing of the authentication entity system 140.In particular, the authenticating processing portion 150 includes anauthenticator character generating portion 152 and a comparison portion154. The authenticator character generating portion 152 generates anauthorizing character sequence 198 to be used to authenticate thetransaction initiated by the user 110. In turn, the comparison portion154 performs a comparison between the authorizing character sequence 198(generated by the authenticator character generating portion 152) andthe display character sequence 194 (provided by the user-customer).

FIG. 5 is a diagram showing further features in accordance with oneembodiment of the invention. Specifically, FIG. 5 shows aspects of thegeneration and the manipulation of the display characters 192 (generatedby the display character generating portion 124) and the authenticationcharacters 196 (generated by the authenticator character generatingportion 152). Both the portions (124, 152) use the same logic (i.e.,random logic as described above) to generate sets of characters (192,196) in some predetermined manner. That is, the display charactergenerating portion 124 will generate the same characters as theauthenticator character generating portion 152 in a progressive manner.As used herein, the generation of a new set of characters by theportions (124, 152) is characterized as generating the next “logicstep”. To explain in other words, the display characters 192 associatedwith a particular logic step, will be the same as the authenticationcharacters 196, if for the same logic step, in accordance with oneembodiment of the invention. Thus, the particular logic step (that eachof the display character generating portion 124 and the authenticatorcharacter generating portion 152 are at) will dictate the particular setof characters that are generated.

As described in detail herein, once the display characters 192 aregenerated on the user authentication device 120, the user observes onlythe particular display positions 138 that the user is assigned, i.e.,the user might make this choice upon activation of the userauthentication device 120. As described in the example above, the usermight have picked the 1, 4 and 5 positions to be the selected positions(from which the user 110 actually uses the characters). The user 110then orders the select display characters 192 in a predetermined manner.In particular, FIG. 1 described above shows an example of this ordering.Once the selected display characters are ordered, this results in a“display character sequence” 194, as used herein. It is this displaycharacter sequence 194 that is submitted to authenticate the desiredtransaction, in accordance with one embodiment of the invention in whichordering is used as the transformation to the display characters 192.

In a parallel manner to the user 110, the authentication entity system140 generates authentication characters 196, selects particularauthentication characters 196 as agreed upon with the customer, and thenorders the selected authentication characters 196. In this manner, theauthentication entity system 140 generates a sequence of characters(e.g. a number) that may be compared with the display character sequence194 (submitted by the user/customer).

It is appreciated that the authentication entity system 140 may performvariations on the above processing methodology. That is, theauthentication entity system 140 may not in fact generate all theauthentication characters 196, but rather only the select authenticationcharacters 196 that will indeed be used in the ordered set, whichconstitutes the authorizing character sequence 198. This approach mightsomewhat limit needed processing since the authentication entity system140 is of course aware that only select characters in the authenticationcharacters 196 will indeed be used. However, this approach wouldgenerally not be performed with the user authentication device 120,since the inclusion of all the display characters 192 (and subsequentdisregarding of some of the display characters 192 by the user 110) ispart of the encryption process.

In further explanation of the invention, FIG. 6 is a high levelflowchart showing an authentication process in accordance with oneembodiment of the invention. As shown in FIG. 6, the process starts instep 200. Then, in step 202 in this example, the customer initiates atransaction. In this example, the transaction is with a merchant. Afterstep 202, the process passes to step 204.

In step 204, the merchant requests various information from the customerso as to process the transaction. Accordingly, in step 206, the customerenters item information, i.e., regarding the particular item that thecustomer is purchasing, and shipping information. It should of course beappreciated that the merchant may request, and the customer may enter,any of a variety of desired information. After step 206 of FIG. 6, thecustomer prepares billing information. Specifically, in step 210, thecustomer generates authentication information to accompany thecustomer's submission of other billing information. Further details ofstep 210 are described in conjunction with FIG. 7 below.

Then, in step 220 of FIG. 6, the customer enters the billing informationincluding authentication information, i.e., including a displaycharacter sequence for use by an authentication entity system inauthenticating the transaction. After step 220, the process passes tostep 230 of FIG. 6.

In step 230, all the information (item, shipping, billing) that thecustomer has prepared is sent to the merchant. Then, in step 240, themerchant sends the authentication information on to the authenticationentity system, i.e., for authentication of the transaction that thecustomer is requesting the merchant to process. Then in step 250, theauthentication entity system authenticates the billing information,including authenticating the display character sequence that thecustomer has provided. Further details of step 250 are described belowwith reference to FIG. 8.

After step 250 of FIG. 6, the process passes to step 280. In step 280,the authentication entity system sends authorization, or alternativelydenial, of the transaction back to the merchant. Then, the processpasses to step 282. In step 282, the merchant authorizes the transactionif the authentication entity system authenticated the display charactersequence. It is appreciated that other authentication processing mayaccompany the authentication of the customer's display charactersequence, i.e., such as authentication of a personal identificationnumber (PIN). That is, in general, the systems and methods of theinvention as described herein may be used in conjunction with othersecurity/authentication measures or technologies.

After step 282 of FIG. 6, the process passes to step 284. In step 284,the process of FIG. 6 ends.

FIG. 7 is a flowchart showing further details of the “customer generatesauthentication information” step 210 of FIG. 6 in accordance with oneembodiment of the invention. The subprocess of FIG. 7 starts in step 210and passes to step 212. In step 212, the customer pushes a button on theuser authentication device, which the customer has been provided. Inresponse to the customer pushing the button, or in some other mannerinterfacing with the user authentication device, in step 214, the userauthentication device advances to a next number sequence based on logiccontained in the user authentication device (i.e., the userauthentication device 120 displays information associated with the next“logic step” as described above). This logic may be in the form of analgorithm that generates a plurality of display characters in somepredetermined manner, i.e., in a manner that an authentication entitysystem 140 may perform a generation of the same numbers based on thesame logic.

Accordingly, in step 215 of FIG. 7, the user authentication devicedisplays a number sequence on the display portion, i.e., one number foreach display position. However, it is of course appreciated that theinvention is not limited to the use of numbers. That is, any suitablecharacter or other indicia might be used in lieu of or in conjunctionwith numbers.

Then, in step 216, the customer recalls the particular positions thatthe user is assigned. That is, out of six display positions, thecustomer only uses three numbers (associated with three displaypositions) so as to generate a display character sequence. In step 216,the customer further reads the numbers from those particular assignedpositions in a particular assigned order. Accordingly, in step 218, thecustomer now has a display character sequence to include in the billinginformation.

After step 218, the process passes to step 219 of FIG. 7. In step 219,the process returns to step 220 of FIG. 6.

FIG. 8 is a flowchart showing in further detail the “authenticationentity system authenticates the billing information, includingauthenticating the display character sequence” step 250 of FIG. 6 inaccordance with one embodiment of the invention. The subprocess of FIG.8 starts in step 250 and passes to step 252.

In step 252 of FIG. 8, the authentication entity system inputs thebilling information, including the display character sequence from thecustomer. Then, in step 253, the authenticator character generatingportion (in the authentication entity system) advances to the next logicstep, i.e., in parallel to the user authentication device 120. That is,the authenticator character generating portion generates authenticationcharacters based on the same logic as is implemented in the userauthentication device. It should be appreciated that somesynchronization feature may be used to coordinate the particular step inlogic, i.e., in generating the next logic step. After step 253 of FIG.8, the process passes to step 254.

In step 254, the authenticator character generating portion in theauthentication entity system generates an authorizing character sequencebased on the authentication characters. Further details of step 254 arediscussed below with reference to FIG. 9. Then, in step 256 of FIG. 8,the display character sequence is compared to the authorizing charactersequence. Further details of step 256 are discussed below with referenceto FIG. 10. After step 256, the process passes to step 258.

In step 258 of FIG. 8, based on a match or no match, the authenticationentity system determines if authorization should be given. Then in step259 of FIG. 8, the subprocess of FIG. 8 returns to step 280 of FIG. 6.

FIG. 9 is a flowchart showing in further detail the “authenticatorcharacter generating portion generates an authorizing character sequencebased on the authentication characters” step 254 of FIG. 8 in accordancewith one embodiment of the invention. In this illustrative subprocess,after starting in step 254 of FIG. 9, the subprocess passes to step 262.In step 262, the authenticator character generating portion retrievesinformation regarding particular fixed positions that the user isassigned. Then, the process passes to step 264.

In step 264, the authenticator character generating portion retrievesthe authentication characters disposed in such particular fixedpositions. This processing is in parallel to the selection of numbers(from the display positions) as is performed by the customer. The, instep 266, the authenticator character generating portion orders theretrieved authentication characters using an order that the user isassigned. As a result, the authenticator character generating portiongenerates an “authorizing character sequence”, which is to be comparedwith the “display character sequence” that is provided by the user. Asshown in FIG. 9, other transformation processes might be used in lieu ofordering select characters. That is, any suitable transformation, e.g.such as ordering or adding a value of one, might be used to convert aplurality of selected characters (shown on the token display) to adisplay character sequence.

Thus, as otherwise noted herein, it is appreciated that some othertransformation might be used in lieu of the ordering of the displaycharacters 192. For example, numbers might be added, some mathematicaltransformation may be applied, and/or the same number might be usedtwice, for example, as well as other variations described herein.

After step 266 of FIG. 9, the process passes to step 268. In step 268,the subprocess of FIG. 9 returns to step 256 of FIG. 8.

FIG. 10 is a flowchart showing in further detail the “display charactersequence is compared to the authorizing character sequence” step 256 ofFIG. 8 in accordance with one embodiment of the invention. Afterstarting in step 256 of FIG. 10, the subprocess passes to step 272.

In step 272, the authentication entity comparison portion compares: theauthorizing character sequence versus the display character sequence(obtained from the customer). After step 272, the process passes to step274. In step 274, the comparison portion considers any variation betweenthe authorizing character sequence versus the display character sequencebased on predetermined thresholds.

In other words, it might be the situation that the display charactersequence does not exactly match the authorizing character sequence.However, if the variation is limited, then the variation might beacceptable so that the authentication entity system will stillauthenticate the transaction. The particulars of what is acceptable andwhat is not acceptable variation may be based on thresholds, as isdesired.

After step 274 of FIG. 10, the process passes to step 276. In step 276,the comparison portion outputs data regarding match or no match back tothe merchant. As a result, the merchant will process or not process thedesired transaction. Then, in step 278 of FIG. 10, the process returnsto step 258 of FIG. 8. Processing then continues as described above withreference to FIG. 8.

In summary, in accordance with one embodiment of the invention, thescheme described herein uses the idea of a remote token synchronizedwith or tracked with a central authentication database, and uses acipher as the secret to authenticate the user. The use of the cipher,which may typically be relatively simple, together with the remote tokensystem provides a novel combination in accordance with one embodiment ofthe invention.

In accordance with embodiments of the invention, the method describedherein may be implemented in innumerable different ways, i.e., such aspicking different simple ciphers. But there must be local and remoteeffectively random numbers, in accordance with one embodiment of theinvention, so that a simple operation on the numbers can be computed bya person and used to authenticate that the person is the right person tobe using the token, rather than simply confirming that the toke iscorrect.

In summary, the invention relates to the notion of using secondencryption with a token that generates changing numbers, so that thesecond encryption embeds or combines additional information with thetoken's number, so that authentication depends on both. The additionalinformation might be a pattern or other information remembered by anindividual, some parameter (like amount) of a payment or transaction, orany other information it is desired to verify.

The invention further relates to the notion of combining information insuch a way that someone who can figure what the token will be generatingmight use it to reconstruct some information remotely, with no fear ofthe information being intercepted by man in the middle attacks. Forexample, this functionality is discussed above in conjunction with usinga purchase amount to generate a display character sequence, i.e., usingthe purchase amount and matching digits (of the purchase amount) withlabels under the display positions.

As discussed above, the authentication entity system 140 authenticates adisplay character sequence that is provided by the customer. Inaccordance with one embodiment of the invention, the authenticationentity system 140 does not allow multiple submissions of a displaycharacter sequence. To explain, the multiple submission checking portion156 (of the authentication entity system 140) may perform a check on anewly submitted display character sequence. This check determineswhether the particular display character sequence has been previouslysubmitted, e.g., previously submitted in a particular period of time. Ifthe multiple submission checking portion 156 determines that theparticular display character sequence has been previously submitted, theauthenticating processing portion 150 will not authenticate the displaycharacter sequence. For example, this might occur in the situation whena customer fails to press button 121 (on the user authentication device120) to generate a new number sequence. That is, a repeat displaycharacter sequence (based on the repeat number sequence) will not beauthenticated. The check for multiple display character sequencesprovides a further fraud prevention measure. To effect such checking, itshould of course be appreciated that the authenticating processingportion 150 may be provided with the ability to keep track of whichdisplay character sequences have been observed.

As described above, in accordance with one embodiment of the invention,the customer pushes a button on the user authentication device 120 and anumber sequence is displayed. From the number sequence, the customerselects characters to form the display character sequence. It isappreciated that if the number sequence is all fives, i.e., 5 5 5 5 5 5(or even 2 2 2 2 4 4), then the particular order that the user hasselected will be irrelevant. For this reason, the content of the numbersequence displayed on the user authentication device 120 may want to becontrolled, i.e., so as to avoid excessive repeat of numbers or othercharacters.

In accordance with a further aspect of the invention, it is appreciatedthat it may be needed to synchronize the user authentication device 120with the authenticating processing portion 150. For example, it might bethe situation that the user authentication device 120 has been exposedto multiple presses of the button (e.g., by a child). If theauthenticating processing portion 150 receives a display charactersequence that does not match with the next generated authorizingcharacter sequence, the authenticating processing portion 150 may “runahead.” That is, the authenticating processing portion 150 may run aheadwith the authorizing character sequences assuming that there have beenpresses of the button 121 which were not submitted to the authenticationentity system 140. The authenticating processing portion 150 may runahead some predetermined number of times, until it finds a match, oralternately it reaches the predetermined number of times and concludesthe display character sequence should not be authenticated.

Other approaches may be used to synchronize the user authenticationdevice 120 to the authenticating processing portion 150. For example,all the display characters (displayed on the user authentication device120) may be provided to the authenticating processing portion 150 (inthe order that the characters are displayed) so as to performsynchronization. That is, given all the display characters in thedisplayed order, the authenticating processing portion 150 can thendetermine the correct point in the progression of the authenticationcharacters.

Alternatively, the customer may provide two sets of display charactersor two sets of display character sequences. These two sets, for example,might then be used by the authenticating processing portion 150 tosynchronize with the user authentication device 120. i.e., based on thetwo sets of display characters, the authenticating processing portion150 could determine where in the progression the user authenticationdevice 120 is disposed.

In accordance with one embodiment of the invention, the userauthentication device 120 may be used in multiple manners. For example,a customer may use the authentication device 120 to generate the displaycharacter sequence as described above, i.e., by selecting the displaycharacters in a particular order. Such use may be implemented forInternet transactions, for example. However, in one embodiment, the sameuser authentication device 120 may also be used by submitting all thedisplay characters to the merchant (and in turn the authenticatingprocessing portion 150). A higher exchange rate may be applied to thesecond use as compared with the exchange rate applied to the first use.For example, such differential in exchange rate might be applied sincethe second use bears higher risk than the first use. Illustratively, thesecond use might occur in a situation in which the user authenticationdevice 120 is used in a restaurant, and a person other than the customeris effecting the transaction.

In accordance with a further embodiment of the invention, a single tokenmay be given to a family, or provided to be used in some other situationin which multiple persons will use the same token, i.e., the same userauthentication device 120. In this situation, the user authenticationdevice 120 will proceed through a progression of display characters,i.e., upon presses of the button 121. However, different users of theuser authentication device 120 will be assigned different displaypositions to read characters, as well as a different order in which toplace those observed characters. Accordingly, for example, if a brotherwere provided the display character sequence of FIG. 1, the brother willgive the 2 5 9 number as shown in FIG. 1. However, if the sister weregiven the same 5 3 7 9 2 1 display number, the sister might be assigned[position 5] [position 4] [position 1], i.e., and thus her displaycharacter sequence would be 2 9 5. Such embodiment allows differentpersons to collectively use the same user authentication device 120,while documenting which person used the user authentication device 120for which transaction. In other words, each persons might be assignedthere own display character sequence. Alternatively, it is of courseappreciated that multiple tokens may be used in a single household.

Further, in accordance with one embodiment of the invention, the sameperson might use the same user authentication device 120, but beassigned different display character sequences for different uses of theuser authentication device 120. For example, given a display number of 53 7 9 2 1, the single user may be assigned ([position 5] [position 4][position 1] (display character sequence would be 2 9 5)) for effectingfinancial transaction versus ([position 5][position 1] [position 4](display character sequence would be 2 5 6)) for opening their garagedoor.

Relatedly, it is of course appreciated that the systems and methods ofthe invention as described herein may be used for any of a variety ofsituations that an authentication procedure is required. For example,the invention may be used for effecting financial transactions,accessing information, opening doors, controlling access to devices(e.g. access to a computer) and/or other situations where anauthentication procedure is needed. In particular the invention may beused to prevent fraud in high risk and/or high value transactions, e.g.,Internet, telephone and ATM transactions. It is also to be appreciatedthat the reduced risk of fraud associated with using the invention mighttypically result in a lower interchange fee, as compared to financialtransactions using other known authentication methods.

Further, it is appreciated that the authentication device 120 may takeany of a variety of forms and/or be combined with other devices. Forexample, the user authentication device 120 may be used or combined witha cellular phone, a PDA, an RFID device, and/or other devices. Forexample, it should be appreciated that the display character sequence,as described herein, may be used in the place of a traditional PIN(personal identification number). Accordingly, the display charactersequence might be used in an ATM transaction. Such might be used toprevent ATM Fraud.

Hereinafter, various embodiments and aspects of embodiments will bedescribed.

In one embodiment, the invention herein described is a method by whichtoken authentication can be incorporated in payment systems with veryminor changes at issuer sites and using mainly existing merchantfacilities. The method may use a token which will generate a display ofnumbers which changes either with time or with uses—and whose values areunpredictable to the external observer who has not complete informationabout the internal (hidden) mechanisms, i.e., processing.

One aspect of the invention is the use of the display of such a token orthe use of a function or selection from that display (the selection orfunction being done by the customer as something he remembers) as anauthenticator reported instead of the existing CVV2 or CVC2 (orequivalent for other card brands) card authenticator string. The CVV2field is normally printed on the back of payment cards and is oftenasked for in phone or net transactions. Its value is checked mainly bythe card issuer. The checking routine described herein can easily beadapted to check the correctness of the token-derived numbers for thatparticular token. Accordingly, this field is already present, it isalready handled by payment networks. Thus, the use of the displaycharacter sequence (in lieu of the CVV2 or CVC2) presents few problemseither for merchant expense or network changes and only very minorexpense for the issuer.

As noted above, a further aspect relating to one embodiment of theinvention is the use of a token display in place of PIN values.Facilities for entering PIN values already are widespread anywherepayment cards exist, and a replacement for a PIN value where thereplacement changes (and especially one which depends on the token thecustomer has and on the selection pattern he knows) gives a muchstronger authentication of the customer than a fixed PIN. Using thisreplacement may require no new network or merchant changes, and as PINsare checked by issuer only, the changes to issuer system would bebasically limited to the PIN validation routines, which are well knownand can be readily added to, i.e., so that issuer would validate thedisplay character sequence, as opposed to a PIN.

Accordingly, in summary, it is noted that the display from a token witha display of variable numbers, or a function or permutation or selectionfrom that display, may be used as an authenticator instead of CVV2 orCVC2 in credit card processing. Further, the display from such a card,or a permutation or selection from such a display, might be used insteadof a PIN in card transactions or the logical equivalent thereof.

As described above, when a customer pushes the button on the token,e.g., the button 121 on the user authentication device 120, the displaywill show some numbers. In one embodiment, two digits display the leastsignificant digits of an internal counter and 3 to 6 digits (preferably6) display part of the result of encrypting the internal counter usingan encryption key which is hidden within the card, and which maydifferent for every card, i.e., the key should be different enough thatanyone analyzing the innards of a card cannot compute the key for adifferent card even though he may know the complete keys of severalother cards. Values may be supplied for these “diversified keys”. In oneembodiment, the encryption algorithm used may be a “strong” cryptoalgorithm, as strong as triple DES or better, but may depend on theparticular use.

In one embodiment, when the button 121 is pressed, the idea is that theinternal counter increments, and the Bank tracks its value, with the aidof the 2 digit low order display. It may be acceptable if the display isin octal radix instead of decimal if cost effective. The display needsto be visible either while the button is pressed, or for an intervalafter the button is pressed, so that the customer has at least 30seconds (and preferably longer) to refer to it as he may need to compareit to other displays or transcribe it or recite it over the phone. Thebutton must of course be very well debounced, and could well be used toe.g. drive a one-shot multivibrator so that it could be impossible toincrement the counter more than once a minute. Something may be providedto ensure that the counter will increment by one only and not by largecounts, i.e., even if the button is electrically noisy.

In one embodiment, the device may live for the 2-3 years that a creditcard is issued for. Thus the power supply must suffice for this and forthe expected number of uses the device will have. It may be preferable,in particular from a marketing perspective to have the device housed ina credit card. As noted herein, the incorporation of RFID functions mayalso be used.

In accordance with one embodiment of the invention, the inventionauthenticates a bank to a customers. On web pages we will want to assurecustomers they are talking to the real bank. Therefore we can ask themfor the 2 digit counter display they see on pushing their button, andusing our tracking data predict the internal counter value. Byencrypting that with the card's key (we may have to ask for customername or account number too), we can predict the display and tell thecustomer “your display will read nnnnnnnn if you are talking to the realbank. If not, hang up immediately and give no further information.”

In one embodiment, the token is authenticated to the bank. In thisaspect of use of the inventive token, the bank asks a customer to pushthe button and read the display. The process includes using the 2 digitdisplay (which may be positioned alongside the display characters) tohelp determine what the counter is and compute the display and see ifthey match. If they don't, it is possible to try to assume the countermight be 100 or 200 or more. Accordingly, a few more encryptions may beattempted to see if the token value provided by the customer is indeedOK. Accordingly, a 2 digit display may be used in addition to thedisplay of FIG. 1 so as to assist in determining where the customer isdisposed in the progression of the token displays, i.e., if thecustomer's kids have been playing with the token button.

In accordance with a further aspect of the invention, a process mayauthenticate the customer to the bank. As described above, each customeris requested to pick an order in which to report digits of the display.We can have the digits numbered in print on the cards to facilitatethis. Then the customer pushes his button, reports digits in the orderhe said he would use. Thus if the display shows: and the customer saidhe would report digits in order 5, 1, 6, 3 (which he has to remember),he tells us the “77” part (if it is agreed upon for him to do so) andreports 3, 5, 9, 1 (the 5th, 1st, 6th, and 3rd digits of the randompart). This relies on the token AND the customer memory. Also anyone inthe middle who might be watching or recording what keys are pressed(remember lots of customer PCs have key loggers running) gets onlyrandom digits. Thus it doesn't matter if someone tries to record whatthe customer typed: it will change every time. Notice too that if thecustomer authenticates this way, it shows he has the token AND knows thepattern all at one go. The number of combinations is 6*5*4*3=360, highenough to cut accidental matches decently. We could ask for more than 4digits if a higher number of combinations were required.

As also described above, it may be that we will want to end any webtransactions by authenticating a second time, so that a thief who brokein and tried to use the credentials later, i.e., for a differenttransaction, would be detected.

In use of the described device for credit card transactions, instead ofweb, the customer may simply report the value of the display (orpossibly the first several digits of the display) when asked for CVV2.It is noted that CVV2 reports may be 5 or more digits long, so thecounter value AND some ciphertext could be reported. Alternatively thefirst part of the ciphertext could be reported for CVV2 if no more than3 digits were accepted. At the back end, we would assume the counterincremented by 1 and compare, repeating for higher counter values till acomparison matched or we gave up, i.e., we would roll the counter aheaduntil we identified a match. In accordance with one embodiment of theinvention, the back end has to track the counter in all cases. We expectthat merchants will quickly start accepting CVV2, and accepting longerCVV2, to handle these devices since the quality of identification willbe much higher than otherwise on phone or net orders, and they mayeliminate substantial monies in fraud losses for merchants per year.

As described above, the user authentication device 121, e.g., a token,of the invention may be in a variety of forms. Also, the userauthentication device 120 may be used in conjunction with a variety offeatures, as described below.

Optical light emitting devices (OLED) generally need to be fabricated onthin substrates with some electronics to control current flow to thelight emitting polymers. It might be sensible to think of building abackplane for such devices (which are very thin and flexible) on whichyou also etch transistors and the like to perform the counting,debouncing, crypto, and possibly display timing as well, in oneembodiment. A bit of flash memory may be built onto this backplane (tohold the counter value and a diversified key, if so desired. This wouldmean that all connections become part of a printed circuit, and thearrangement might be in the form of a small rectangle laid down in theinside of a card, to be covered by a transparent cover. Then theconnections might only be to a battery and button.

In accordance with one embodiment of the invention, a piezoelectricelement may be used for power. In such an arrangement, the customerwould press on a printed circle, i.e., to press the element and generateelectricity, avoiding button contacts. Also, pressing or bending energymight be used, if workable.

In accordance with one embodiment of the invention, a thin RFID ICbonded onto a display backplane would allow the cryptography,accumulation, password setup, etc. all to be done on a not too heavilyaltered RFID chip.

Initializing the crypto key might be done via fuses, via RFID, or acapacitive feed scheme which could use pulse trains to set the keys upone bit at a time without needing full contact. This can be sharedseparately if need be. Other schemes can be used.

A variety of power sources may be used to power the button 121. Forexample, photoelectric cells, electrets, and/or known batteryarrangements may be used.

It is noted that the device must be reliable during its life, eventhough it will typically live in a wallet or purse.

In accordance with one embodiment of the invention, the userauthentication device 120 may include a display that has 2 parts, i.e.,a 2 digit field and a longer field (which might be 6 digits long, forexample). Every time the customer presses the button, the 2 digit fieldincrements and the longer field gets a set of what look like randomnumbers. No two card sequences are like.

In accordance with one aspect of the invention described above, anauthenticating entity may wish to insure that a transaction amount isapproved by the customer. The customer may take the first few digits ofthe amount (the purchase amount) and use them as positions to report onthe display. As described above we might have display digitsrepresenting 2 digits each and have the customer enter the displayednumbers at those positions. What gets actually transmitted is a fewrandom digits, but they can be checked against the amount as well as thedevice identity, proving that someone with the same device whoauthenticated moments before sent an acceptance for the amount of thetransaction.

The systems and methods of the invention provide a wide variety ofadvantages. In accord with some embodiments, the inventive device maylargely eliminate phishing: there is no point in stealing things likecard numbers or account numbers when the variable device is required toget money. In accord with some embodiments, the inventive device mayvastly reduce phone or net fraud. This will cut both issuer and merchantlosses. In accord with some embodiments, the inventive device mayeliminate intra-family fraud so long as individual devices are given toeach person and so long as the people don't give their patterns away. Inaccord with some embodiments, the inventive device may make customerdata cheaper to handle because less of it will be privacy sensitive.People don't mind when their phone numbers are given out most of thetime. If their card number can't be used to rob them or damage theircredit, they won't care if it is given out either. In accord with someembodiments, the inventive device may cut fraud in ATMs and/or atmerchants if the device is used to generate pseudo PINs which wouldauthenticate transactions. Because the transmitted data is in effectencrypted, even cameras watching PIN pads will be useless in stealingsuch credentials. It is noted that most merchants have PIN pads alreadywhich could be used in implementation of the invention. In addition, thedevice shows the customer that his credentials are being generatedsecurely and shows that its issuer is doing something very tangible inprotecting the customer's identity. The savings to merchants aresizeable and should in addition give some merchants good incentives toprefer these devices and to give incentives to customers to use them.

Further examples of use of the user authentication device 120, inaccordance with embodiments of the invention, are set forth below.

In accordance with one embodiment of the invention, for net use, i.e., apurchase over the Internet, the customer might give his username andpassword. Then, the customer gives the value of the low order digits.The authentication entity then determines what the ciphertext (0:2)should be and conveys such to the customer, telling customer “if thisdoesn't match your display, you are talking to a fraud site. Then, ifciphertext (0:3) is OK, the authentication entity may ask the customerto enter ciphertext (3:5) and check that it is also valid. For exampleas used in this example, 3:5 means the digits shown in positions 3, 4and 5.

To explain further, in an embodiment, the customer might provide half ofthe displayed digits to an authentication entity. Based on theseprovided digits, the authentication entity can then (if needed)determine where the customer is in the progression of the token. Theauthentication entity can then generate displayed characters(corresponding to those displayed by the customer), and theauthentication entity then provides at least a portion of such displayedcharacters back to the customer. For example, the authentication entitymight provide a portion or all of the displayed characters back to thecustomer. In this manner, the authentication entity knows they aredealing with a particular customer and the customer knows they aredealing with a particular authentication entity. Variations of thisembodiment are of course possible regarding what portion of a characterdisplayed is provided by what entity, e.g., what characters are providedby the customer and what characters are provided by the authenticationentity.

Further, the two parties authenticating may of course perform any agreedupon transformation to the characters displayed on the token (or otherdevice), i.e., such as providing select numbers in a particular order,or adding a 1 to each displayed number, for example, or any othersuitable transformation. Accordingly, the providing of a select numberof digits in a particular order is merely one transformation that mightbe performed.

As noted above, the authentication entity might provide a portion or allof the displayed characters back to the customer (or a transform of thedisplayed characters), and in this manner, the customer knows they aredealing with a particular authentication entity. Alternatively, or inaddition to, the authentication entity might provide a portion or all ofthe next pattern, e.g., the next set of display characters, which maythen be verified by the customer. The next pattern may also of course betransformed in some manner. Thus, in some agreed upon manner toauthenticate, the authentication entity (or the customer) may convey tothe other a portion or all of the display characters (or theirequivalent such as the authentication characters 196), some transform ofthe display characters, and/or a portion or all of the next set ofdisplay characters (which may also be transformed), for example.

In accordance with one aspect of the invention relating to use withcredit card transactions, the issuer might offer a direct validationservice to merchants. The issuer could then do as much of theauthentication processing as desired. Further, it would place the issuerin a position to check passwords or take a voice sample, or performvarious other authentication, as may be desired. Further, the issuermight use ciphertext(3:5) instead of CVV2 in transaction informationthat was sent with the charge. It is noted the reported track 2 data maybe used to capture two or so digits of low order counter indiscretionary data fields. As issuer, we would recognize that thepresented CVV2 was a variable one and validate accordingly, i.e., eithersearching the next several counter values for the customer, or using thediscretionary data fields to reduce the amount of crypto to be done,e.g. reduce the need to roll ahead in search of a match.

In accordance with one embodiment of the invention, for ATM processing,the card may be inserted, and read by the ATM. The card would then beejected and the customer enters the value of counter low digits, checksthat the right ciphertext is displayed by the ATM (i.e., the displaycharacter sequence as described above), and only then enters her PINand/or other ciphertext, as may be desired. This processing would conveythe customer had some reason to think the ATM was communicating with theissuer before giving his PIN.

In accordance with one embodiment of the invention, the system usesdifferent digits of ciphertext to authenticate to the customer that heis talking to the bank first, then to authenticate to the bank that thecustomer is who he claims to be. That is, the process checks that thecard's identity is real. Tying the card to the customer requires askingfor another password/PIN, or sampling voice, or the like. It might bethat voice or a PIN recognition measures are required for higher valuetransactions, and not for low value ones.

For phone orders, the customer may be asked for the low digits of thecounter and the ciphertext (at least one of the sets). Either a Bankauthentication service could be called with this information and thecard number/customer name, or the low digits could be passed indiscretionary characters in Track 2 of card image data. (For time basedcard displays some of the ciphertext could be used as CVV2 not needingany additional data passed back.) Merchants knowing the variable numbermatched would be assured it would be less likely chargebacks could occurbecause the authentication was stronger. In one embodiment, theinvention would exist on every credit card, and the only area needingchange would be the issuer backend, i.e., the routine that checks CVV2.Such backend would know or compute the diversified key on the card, andtrack and encrypt the card counter and verify the ciphertext.Accordingly, processing change would be negligible.

In accordance with embodiments of the invention, it is appreciated thatnon-numeric indicia might be used along with, or in lieu of, thenumerics described above, as may be desired. That is any symbol,graphic, picture, or other information representation, for example,might be used in lieu of, or along with, the numerics discussed above,as may be desired.

Further, it is appreciated that a constant value (i.e., a constant:number, symbol, graphic, picture, or other information representation,for example) might be used along with a variable value, or a set ofvariable values, which are described above.

As described above, FIGS. 1-4 and 10 show embodiments of structure andsystem of the invention. Further, FIGS. 5-10 show various steps inaccordance with one embodiment of the invention. It is appreciated thatthe systems and methods described herein may be implemented using avariety of technologies. Hereinafter, general aspects regarding possibleimplementation of the systems and methods of the invention will bedescribed.

It is understood that the system of the invention, and portions of thesystem of the invention, may be in the form of a “processing machine,”such as a general purpose computer, for example. As used herein, theterm “processing machine” is to be understood to include at least oneprocessor that uses at least one memory. The at least one memory storesa set of instructions. The instructions may be either permanently ortemporarily stored in the memory or memories of the processing machine.The processor executes the instructions that are stored in the memory ormemories in order to process data. The set of instructions may includevarious instructions that perform a particular task or tasks, such asthose tasks described above in the flowcharts. Such a set ofinstructions for performing a particular task may be characterized as aprogram, software program, or simply software.

As noted above, the processing machine executes the instructions thatare stored in the memory or memories to process data. This processing ofdata may be in response to commands by a user or users of the processingmachine, in response to previous processing, in response to a request byanother processing machine and/or any other input, for example.

As noted above, the processing machine used to implement the inventionmay be a general purpose computer. However, the processing machinedescribed above may also utilize any of a wide variety of othertechnologies including a special purpose computer, a computer systemincluding a microcomputer, mini-computer or mainframe for example, aprogrammed microprocessor, a micro-controller, a peripheral integratedcircuit element, a CSIC (Customer Specific Integrated Circuit) or ASIC(Application Specific Integrated Circuit) or other integrated circuit, alogic circuit, a digital signal processor, a programmable logic devicesuch as a FPGA, PLD, PLA or PAL, or any other device or arrangement ofdevices that is capable of implementing the steps of the process of theinvention.

It is appreciated that in order to practice the method of the inventionas described above, it is not necessary that the processors and/or thememories of the processing machine be physically located in the samegeographical place. That is, each of the processors and the memoriesused in the invention may be located in geographically distinctlocations and connected so as to communicate in any suitable manner.Additionally, it is appreciated that each of the processor and/or thememory may be composed of different physical pieces of equipment.Accordingly, it is not necessary that the processor be one single pieceof equipment in one location and that the memory be another single pieceof equipment in another location. That is, it is contemplated that theprocessor may be two pieces of equipment in two different physicallocations. The two distinct pieces of equipment may be connected in anysuitable manner. Additionally, the memory may include two or moreportions of memory in two or more physical locations.

To explain further, processing as described above is performed byvarious components and various memories. However, it is appreciated thatthe processing performed by two distinct components as described abovemay, in accordance with a further embodiment of the invention, beperformed by a single component. Further, the processing performed byone distinct component as described above may be performed by twodistinct components. In a similar manner, the memory storage performedby two distinct memory portions as described above may, in accordancewith a further embodiment of the invention, be performed by a singlememory portion. Further, the memory storage performed by one distinctmemory portion as described above may be performed by two memoryportions.

Further, various technologies may be used to provide communicationbetween the various processors and/or memories, as well as to allow theprocessors and/or the memories of the invention to communicate with anyother entity; i.e., so as to obtain further instructions or to accessand use remote memory stores, for example. Such technologies used toprovide such communication might include a network, the Internet,intranet, Extranet, LAN, an Ethernet, or any client server system thatprovides communication, for example. Such communications technologiesmay use any suitable protocol such as TCP/IP, UDP, or OSI, for example.

As described above, a set of instructions is used in the processing ofthe invention. The set of instructions may be in the form of a programor software. The software may be in the form of system software orapplication software, for example. The software might also be in theform of a collection of separate programs, a program module within alarger program, or a portion of a program module, for example Thesoftware used might also include modular programming in the form ofobject oriented programming. The software tells the processing machinewhat to do with the data being processed.

Further, it is appreciated that the instructions or set of instructionsused in the implementation and operation of the invention may be in asuitable form such that the processing machine may read theinstructions. For example, the instructions that form a program may bein the form of a suitable programming language, which is converted tomachine language or object code to allow the processor or processors toread the instructions. That is, written lines of programming code orsource code, in a particular programming language, are converted tomachine language using a compiler, assembler or interpreter. The machinelanguage is binary coded machine instructions that are specific to aparticular type of processing machine, i.e., to a particular type ofcomputer, for example. The computer understands the machine language.

Any suitable programming language may be used in accordance with thevarious embodiments of the invention. Illustratively, the programminglanguage used may include assembly language, Ada, APL, Basic, C, C++,COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, REXX,Visual Basic, and/or JavaScript, for example. Further, it is notnecessary that a single type of instructions or single programminglanguage be utilized in conjunction with the operation of the system andmethod of the invention. Rather, any number of different programminglanguages may be utilized as is necessary or desirable.

Also, the instructions and/or data used in the practice of the inventionmay utilize any compression or encryption technique or algorithm, as maybe desired. An encryption module might be used to encrypt data. Further,files or other data may be decrypted using a suitable decryption module,for example.

As described above, the invention may illustratively be embodied in theform of a processing machine, including a computer or computer system,for example, that includes at least one memory. It is to be appreciatedthat the set of instructions, i.e., the software for example, thatenables the computer operating system to perform the operationsdescribed above may be contained on any of a wide variety of media ormedium, as desired. Further, the data that is processed by the set ofinstructions might also be contained on any of a wide variety of mediaor medium. That is, the particular medium, i.e., the memory in theprocessing machine, utilized to hold the set of instructions and/or thedata used in the invention may take on any of a variety of physicalforms or transmissions, for example. Illustratively, the medium may bein the form of paper, paper transparencies, a compact disk, a DVD, anintegrated circuit, a hard disk, a floppy disk, an optical disk, amagnetic tape, a RAM, a ROM, a PROM, a EPROM, a wire, a cable, a fiber,communications channel, a satellite transmissions or other remotetransmission, as well as any other medium or source of data that may beread by the processors of the invention.

Further, the memory or memories used in the processing machine thatimplements the invention may be in any of a wide variety of forms toallow the memory to hold instructions, data, or other information, as isdesired. Thus, the memory might be in the form of a database to holddata. The database might use any desired arrangement of files such as aflat file arrangement or a relational database arrangement, for example.

In the system and method of the invention, a variety of “userinterfaces” may be utilized to allow a user to interface with theprocessing machine or machines that are used to implement the invention.As used herein, a user interface includes any hardware, software, orcombination of hardware and software used by the processing machine thatallows a user to interact with the processing machine. A user interfacemay be in the form of a dialogue screen for example. A user interfacemay also include any of a mouse, touch screen, keyboard, voice reader,voice recognizer, dialogue screen, menu box, list, checkbox, toggleswitch, a pushbutton or any other device that allows a user to receiveinformation regarding the operation of the processing machine as itprocesses a set of instructions and/or provide the processing machinewith information. Accordingly, the user interface is any device thatprovides communication between a user and a processing machine. Theinformation provided by the user to the processing machine through theuser interface may be in the form of a command, a selection of data, orsome other input, for example.

As discussed above, a user interface is utilized by the processingmachine that performs a set of instructions such that the processingmachine processes data for a user. The user interface is typically usedby the processing machine for interacting with a user either to conveyinformation or receive information from the user. However, it should beappreciated that in accordance with some embodiments of the system andmethod of the invention, it is not necessary that a human user actuallyinteract with a user interface used by the processing machine of theinvention. Rather, it is contemplated that the user interface of theinvention might interact, i.e., convey and receive information, withanother processing machine, rather than a human user. Accordingly, theother processing machine might be characterized as a user. Further, itis contemplated that a user interface utilized in the system and methodof the invention may interact partially with another processing machineor processing machines, while also interacting partially with a humanuser.

It will be readily understood by those persons skilled in the art thatthe present invention is susceptible to broad utility and application.Many embodiments and adaptations of the present invention other thanthose herein described, as well as many variations, modifications andequivalent arrangements, will be apparent from or reasonably suggestedby the present invention and foregoing description thereof, withoutdeparting from the substance or scope of the invention.

Accordingly, while the present invention has been described here indetail in relation to its exemplary embodiments, it is to be understoodthat this disclosure is only illustrative and exemplary of the presentinvention and is made to provide an enabling disclosure of theinvention. Accordingly, the foregoing disclosure is not intended to beconstrued or to limit the present invention or otherwise to exclude anyother such embodiments, adaptations, variations, modifications orequivalent arrangements.

1. A system for processing authentication information associated with atransaction effected by a user, the system comprising: a userauthentication device comprising: a display comprising a plurality ofdisplay positions; and a user authentication device computer processorgenerating a display character for each display position based on logicand a predetermined progression, and outputting the display charactersto the display positions so as to be readable by the user; and anauthentication entity system comprising: an input portion that receivesan input character sequence consisting of fewer than all of the displaycharacters displayed on the user authentication device; and anauthentication system computer processor that: generates a set ofauthenticating characters based on the logic and the predeterminedprogression and uses a stored user-selected pattern to select fewer thanall of the authenticating characters as an authorizing charactersequence, the stored user-selected pattern specifying an order of theauthentication characters in the authentication character sequencerelative to the display positions; compares the authorizing charactersequence to the input character sequence; and authenticates thetransaction based on the comparison.
 2. (canceled)
 3. The authenticationsystem of claim 1, wherein the logic further comprises a transformationof data. 4-5. (canceled)
 6. The authentication system of claim 1,wherein the user authentication device is associated with credit carduser; and the authentication entity system being maintained by a bank.7. The authentication system of claim 6, wherein the logic uses analgorithm to generate the plurality of display characters, the algorithmgenerating the plurality of display characters in a predetermined mannerknown to the authentication entity system.
 8. The authentication systemof claim 1, wherein the user authentication device further includes adisplay button, and the user authentication device operable such thatpressing of the display button by the user results in the displaycharacters being displayed in the respective display positions.
 9. Theauthentication system of claim 1, wherein the communication channel isone selected from the group consisting of a telephone line channel,radio signal, infrared and network. 10-11. (canceled)
 12. Theauthentication system of claim 1, wherein each display character is anumber.
 13. The authentication system of claim 1, wherein the userauthentication device is in the form of a handheld token.
 14. Theauthentication system of claim 1, wherein the user authentication deviceis in the form of a program running on a computer, the computer isconnected to a network. 15-38. (canceled)
 39. The authentication systemof claim 1, wherein the predetermined transformation includes adding avalue of 1 (one) to select characters in the display portion. 40-43.(canceled)
 44. An authentication system maintained by an authenticationentity that processes authentication information associated with atransaction effected by a user, the authentication system comprising: aninput portion that receives an input character sequence from a customerconsisting of fewer than all of the display characters displayed by auser authentication device associated with the customer using aplurality of display positions; a processing portion comprising at leastone computer processor that generates a set of authenticating charactersbased on logic and users a stored user-selected pattern to select fewerthan all of the authenticating characters as an authorizing charactersequence, the stored user-selected pattern specifying an order of theauthenticating characters in the authenticating character sequencerelative to the display positions; and a comparison portion thatcompares the authorizing character sequence to the input charactersequence and authenticates the transaction based on the comparison;wherein the display characters and the authenticating characters aregenerated using the same logic.
 45. (canceled)